I added a quick --wait=EVENT option to flux resource eventlog and a sharness test. Will remove WIP - maybe good for a start that we can experiment with a bit?

Yeah, let me see if I can generalize the JournalConsumer class to also work with the resource eventlog.

Did we want to add this to 0.71 as an experimental feature?

I was halfway through reviewing it and had a few commits that abstract the current Python JournalConsumer class to add a ResourceJournalConsumer class and I was currently writing some tests.

Have we estimated what the size of the in-memory history of all events would be like on something like Elcap with a long uptime?

That might be worrisome actually, now that you mention it. Perhaps we'll need some way to cull non-persistent events (e.g. other than drain/undrain) that are older than a threshold. It might be a bit too last minute to add that here, sadly.

I'm not sure there's a rush to add this as experimental because I'm not sure there's an immediate use case without the Python consumer class (unless I'm forgetting something!)

I think this is a priority for @kkier but there is little advantage in putting this in as is - in fact it may cause problems. Let's try to deliver a good first step in the next release.

Just confirming - this is a priority for me (and the people I report to on both sides of the aisle, as it were), but if it ends up in an off-cycle release that I have to manually distribute, that's a thing I can deal with.

but if it ends up in an off-cycle release that I have to manually distribute, that's a thing I can deal with.

To be clear, although it's not that hard on our end to produce one-off tags and packages, this particular change modifies a core service and would require downtime to distribute.

One thing I've noticed in my testing is that canceling the journal RPC with resource.journal-cancel doesn't seem to result in ENODATA eventually being sent to the client. This differs from the job manager journal service and would slightly complicate the implementation of Python interfaces with a shared base class.

Of course it is possible I've made a mistake in testing.

but if it ends up in an off-cycle release that I have to manually distribute, that's a thing I can deal with.

To be clear, although it's not that hard on our end to produce one-off tags and packages, this particular change modifies a core service and would require downtime to distribute.

100% understood, it is what it is.

canceling the journal RPC with reosurce.journal-cancel doesn't seem to result in ENODATA eventually being sent to the client

It should. (if spelled correctly :-) However I didn't add a test for that so I should verify.

I stumbled across the problem I think:

diff --git a/src/modules/resource/reslog.c b/src/modules/resource/reslog.c
index 61aae1218..513d54cc6 100644
--- a/src/modules/resource/reslog.c
+++ b/src/modules/resource/reslog.c
@@ -328,7 +328,7 @@ static void journal_cb (flux_t *h,
         errstr = "journal requires streaming RPC flag";
         goto error;
     }
-    if (send_backlog (reslog, msg))
+    if (!send_backlog (reslog, msg))
         return;
     if (flux_msglist_append (reslog->consumers, msg) < 0)
         goto error;

Aww I tested that. Must have broken it with a last minute change. I need to add a test too :-(

Ok some small changes:

• fix the bug @grondo pointed
• renamed -f to -F to match python class (for future work by @grondo)
• cover -F in test
• rebase on current master

Thanks! I'll set MWP.

Codecov Report

Attention: Patch coverage is 68.15287% with 50 lines in your changes missing coverage. Please review.

Project coverage is 79.50%. Comparing base (1fbd1dd) to head (6769b2e).
Report is 8 commits behind head on master.

@@            Coverage Diff             @@
##           master    #6586      +/-   ##
==========================================
- Coverage   79.53%   79.50%   -0.04%     
==========================================
  Files         531      531              
  Lines       88213    88354     +141     
==========================================
+ Hits        70160    70242      +82     
- Misses      18053    18112      +59